Making The Sims the Sims 


How we make objects and 
Sims behaviors in Sims2. 


Who Am I? 


° Jake Simpson. 

¢ Lead simulator Engineer on Sims2 - 
currently working on top super secret 
level 10ZZZ project, that no one 
would ever guess in a million years. 


¢ Email jmsimpson@maxis.com 


¢ Website www.jakeworld.org 


Talk Structure 


¢ Definitions - What’s a Sims “object”? 

¢ Process - how we define what an 
object is going to be. 

¢ The tools we use. 
- In depth look at Edith Object / 
Scripting / Debugging Tool. 

¢ Discussion of possible alternative 
scripting approaches. 


¢ Demo of making an object / Questions. 


Major Thank You's 


¢ The entire Object Engineering Team 
on Sims2. 


¢ Patrick Barret, Jamie Dornbos, Eric 
Bowman and Don Hopkins. 


¢ And, of course, Will Wright. 


Definition of a Sims Object 
(part 1) 


¢ An object is a collection of data, that has an 


executable thread within it that when placed in 
a lot will run code by default. 


Contains localized String lists, executable 
scripts, common definition meta data, 
animation lists, routing information, advertising 
information, interaction definitions,- may also 
contain model information. 


Some objects are physical - cars, toilets etc., 
some are not - objects that handle visitors 
arriving on the lot, the weather, time of day, 
social objects etc. 


Definition of a Sims Object 
(part 2) 


¢ Object usage - placed on lot, game engine 
automatically runs initialization scripts on it, and 
then will run one ‘main’ script every frame. 


¢ All objects have ‘advertising’ data in them, 
imported from an Excel spreadsheet - data specific 
to Sims motives. This allows the in code decision 
maker to decide what object any given sim might 
want to use next autonomously, given it’s current 
motive values, distance from object, sim age etc. 


¢ All data necessary for game usage Is contained 
within an object - excepting outside assets such as 
models, textures, animations and sounds (objects 
were designed to have this included, but too much 
duplication of generic data). 


The process of building an 
object (part 1) 


¢ Design requirements “We need an object 
that satisfies the Fun Motive” - factor in 
theme (if an expansion pack). 


Design Meeting to decide the rules of the 
object - how does It fulfill motives, is ita 
group object, does it need repairing, how 
does it fit in with everything else in the 
game? 

Technical Meeting to decide the scope of the 
object, and what will be necessary to 
actually build it (animations, models, 
textures, coding etc). Also defines at that 
point if more engine support is required. 


The process of building an 
object (part 2) 


Scheduling of models (skeleton templates If 
several objects of same type), animation, 
textures, sound and scripting. Animation and 
scripting tend to occur at the same time, 
since they are interleaved. 


Sound comes after animations are locked 
down, since they are animation timing 
dependent. 

Generally 1 scripting engineer, 1 or 2 
animators, 1 modeler and 1 texture artist per 
object. 

ne will go on right till ship - Tuning 
also. 


Object Tools / Pipeline 


For Animation / models / textures we go 
Output from package -> Go2Sco -> Game 
ready data. 


For objects we use the Edith Tool. 


For tuning / neighborhood / lot building we 
use imported Excel spreadsheets and the 
game tools for in game construction. 


For various viewing tools, we use home 
grown animation viewers, some in C#, 
some in MFC, using either game engine 
7 or managed C from within the game 
itself. 


The Edith Editor (part 1) 


¢ MFC front end on the object pipeline. 


¢ Evolution from Sims1 (and originally 
Mac!!) through expansion packs to 
revised edition in Sims2. 


¢ Early version used also in all the 
console games. - Commonality of 
concept, slightly different execution - 
exchangeable scripting engineers. 


The Edith Editor (part 2) 


¢ Completely In Game - with 
Implications! 
¢ Scripts can be changed in real time. 


¢ Debugging is done in real time, with 
breakpoints, data breakpoints, edit- 
and-continue of scripts and automatic 
saving of changes. 

¢ All text is entered via Edith, and the 
exported, localized and re-imported via 
an external tool. 


Edith Editor Demonstration 


¢ Lets see what we've been talking 
about In action. 


The Simantics Language (part 


1) 


Real time parsed / interpreted, not compiled. 
Binary format, not text (although we do have 
text exporters). 

Fixed primitive sizes. 

All relative - no trig functions to avoid 
overhead of parsed math functions. 

E.g. “Route relative to this object” rather 
than “Route to position X, Y and Z in world”. 
Scripts callable directly from hooks in code, 
SO easy object specific logic. 


The Simantics Language (part 
2) 


¢ Multi-threaded - each object has it’s own thread. 


° Yielding primitives ‘wait’ until their functionality 
is complete - E.g Routing, animation, sleeping 
etc. 

¢ Each thread has stack - can pass data to 
functions like any other language. 


¢ Internal error checking - when script crashes or 
errors occur (e.g routing errors), the object 
‘resets’ to a known state. In the case of sims, it 
resets them to the last saved state and 
repositions them in the world, as well as 
resetting any objects they were interacting with. 


Edith / Simantics 


° Pros 
- Real time application. 
- Not easily reverse engineered. 
- All functionality in one place. 
- Almost release quality tool. 
- Many profiling and ‘ease of use’ features. 
- Real limits on CPU intensive scripting operations. 
- Fast and easily addition of new primitive types. 
- Automatic real-time error checking and recovery. 
- Tailored for use in Sims (or any other) games. 


Edith / Simantics 


¢ Cons 


- Have to have game A edit. If problem 
with game executable, work stops. 


- Much empirical knowledge required - what 
definitions do and where. 


- Large ramp up to be productive. 


- Primitives can get complicated and aren't 
resizable data wise. 


- Not transferable skill set. 
- Overhead of parsing - bugs in parsing hard to find. 


- Not easily scaleable to 10x objects (although 
that’s more a C++ problem than a Simantics one). 


Scripting Approach 
Discussion 


Parsed vs Interpreted / Compiled. 

Requires Interpreted to do edit and contine (which Is 
necessary for rapid development) - compiled for final 
release, but then you've got two paths for testing. What 
works in one might now work in another. 

Parsing is faster to develop with, but may have runtime 
overheads. It does have the advantage of being home grown 
and therefore game specific. 

Plain Text or homegrown editors factor into this greatly. 


Lua / Python usage. 

More overhead (particularly in the case of Python), plus the 
API code is more complex - tries to be all things to all people. 
Hard to limit functionality to stop bad practices. 

But transferable skill set, can hire people ready to work on 
day 1, plus a known quantity - Lua just ‘works’. Potential for 
mod development much greater too. 


Either way, debugging is critical for rapid development - so 
home grown debuggers are the way to go. 


Object Construction oddities 


Hierarchical script construction - like C++ 
inheritance but file based. 

Semi global files for object types contain common 
Scripts, where as specific object files contain that 
which is object specific (ie Model, animations 
Specific to that object within type) - makes for 
fast modification of group functions / variables 
and also for expansion pack updating. 

Exporting / importing tuning constants for outside 
modification. 

Profiling / debugging tools become very important 
- more than one place to create bugs or slow 
code. 


Demo and Questions 


¢ My attractive* assistant will now create an object 
from scratch within 10 minutes to demonstrate 
the power of the Sims2 object pipeline. 


¢ While he is doing that, questions? 


To whom, we aren’t Sure. 


